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REMARKS 

Upon entry of this Response, claims 1-22, 24-27, 29-32 and 34-36 remain 
pending in the present application. Claims 22, 27, and 32 have been amended. 
Applicant requests reconsideration of the pending claims in view of the following 
remarks. 

In Item 1 of the Office Action, claims 1-21 have been rejected under 35 U.S.C. 
§1 02(e) as being anticipated by U.S. Patent Application Publication 2001/0052901 
A1 filed by Parekh et al. {hereafter "Parekh"). Anticipation under §102 "requires the 
disclosure in a single prior art reference of each element of the claim under 
construction. W.L. Gore and Associates. Inc. v. Garlock. Inc .. 220 USPQ 303, 313 
(Fed. Cir. 1983). Applicant reasserts that the rejection of claims 1-21 Is improper for 
the reasons that follow. 

Claim 1 in its current state provides the following: 

1 . A system for generating a graphical user interface 
(GUI), comprising: 

a processor circuit having a processor and a 

memory; 

GUI generation logic stored on the memory and 
executable by the processor, the GUI generation logic comprising: 
. logic to generate an input field in the graphical 
user interface, the input field being associated with an input 
item in a template, the template expressing a content of a 
digital document in a markup language file; and 

logic to automatically label the input field in the 
graphical user interface with a content of an input field tag in 
the template, the input field tag being associated with the 
input item in the template. 

Applicant asserts that Parekh fails to show the logic to automatically label the 

input field in the graphical user interface with a content of an input field tag in the 

template, where the template expresses a content of a digital document in a mark-up 

language file as claimed. In this respect, the Office Action states: 

"Parekh also discloses automatically labeling an input field label in 
the graphical user interface from an input field tag in the template, 
the input field tag being associated with the input item in the 
template, wherein the steps of using templates to label the 
documents is clearly done through an automated process (page 1 , 
paragraph 14, lines 8-20)." (Office Action, pages 2-3) 

Applicants respectfully disagree. At paragraph 14, Parekh states: 
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An NTDS application can be considered to be a dialogue between 
a user and the NTDS server. The NTDS uses templates to create 
customer-application screens. These templates can be customized 
for each application variation, for devices, and for regional 
requirements. As illustrated in Fig. 1 , NTDS uses three template 
files, a canonical template file, a screen definition file, and a device 
template file, to generate application screens. The screen template 
generator invention automates this creation of these screen 
template files. Each file defines a different aspect of the customer 
screen generation process. A dialogue screen contains elements 
defined in the canonical template files (CTF), screen definition files 
(SDF), and device template files (DTF). The screen object in 
presentation manager uses the information contained in these files 
to create the dialogue screens during run time. The DTF files 
contain device-specific information for a particular output device 
and is created by looking at an HTML file, which serves as a 
template (created from an APS specification), and substituting 
certain of its tokens with its DTF versions. The DTF tokens have 
identifiers that can be used at run time to reference the elements in 
the dialogue, so that its properties can be dynamically controlled. 
The CTF file contains all the identifiers used in the DTF file. The 
SDF files are subsets of CTF files and are used to simplify the 
handling of the fixed phrases residing in databases. The process of 
manually creating these files is tedious and error prone. The 
purpose of the screen template generator is to simplify and 
automate the creation of these template files." 

Applicant asserts that the above discussion does not show or suggest the 
concept of automatically labeling an input field in a graphical user interface with a 
content from an input field tag in the template. Specifically, Parekh discusses a 
"Screen Object and Presentation Manager" that uses information contained in the 
files described to create dialogue screens during a run time. While the "DTF files" 
include device-specific information created by looking at an HTML file, tags are not 
taken from any of the "template files" and used to label input fields in a graphical 
user interface. Specifically, in the case of the "DTF files" described above, certain 
tokens of the DTF files are inserted. However, there is no discussion of how the 
content of an input field tag is used as a label within a graphical user interface for 
an input field, in addition, Parekh does not show or suggest such an element in any 
other portion. 

Accordingly, Applicant asserts that Parekh fails to show or suggest all of the 
elements of claim 1 as currently pending. In addition, it is asserted that claims 8 and 
1 5 include limitations similar in scope with those of claim 1 . Accordingly, Applicant 
respectfully requests that the rejection of claims 1 , 8 and 15 be withdrawn. In 
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addition, Applicant requests that the rejection of claims 2-7, 9-14, and 16-21 be 
withdrawn as depending from claims 1, 8, and 15, respectively. 

In addition, claim 5 includes "logic to generate a section label in the graphical 
user interface from the section tag in the template; and logic to generate the input 
field in the graphical user interface in association with the section label." Applicant 
notes that claims 12 and 19 include limitations similar in scope with those of claim 5 
above. 

With reference to claims 5, 12, and 19, the Office Action states: 

"Parekh discloses a section label and means for generating them in 
the graphical user interface from the section tag in the template and 
wherein these section labels are associated with an input field in 
the graphical user interface. These labels serve as options for the 
user to choose from within the input field box. See page 7. 
paragraph 109, lines 5-7." (Office Action, page 3) 

At page 7, paragraph 109, Parekh states: 

"Syntax6=<TAG Attributes><Other Tags></TAG>-this syntax 
describes ati HTML command consisting of a tag, followed by zero 
or more attributes, followed by some other markup tags, followed 
by a terminating tag. For example: <SELECT NAM E="pepper" 
Size="4" MULTIPLE><OPTION>Malabar<OPTION>Telicherry 
<OPTION >Red </SELECT>" 

Applicant asserts that noting in the cited paragraph 109 shows or suggests 
the concept of generating a section label in a graphical user interface, where the 
input field generated in the graphical user interface is generated in association with 
the section label. In this respect, section labels provide for an easier understanding 
of the graphical user interface itself and section labels are harvested separately from 
other tags in the template. Specifically, section labels are identified from section 
tags in the template, and the logic understands the difference. 

Applicant asserts that the above excerpt fails to show or suggest the specific 
creation of a section label in a graphical user interface from a section tag and 
generating the input field in the user interface in association with section label as 
claimed. Rather, the citation of paragraph 109 above mainly refers to a markup 
approach of listing various options to be selected as shown. Accordingly, Applicant 
asserts that Parekh fails to show or suggest all of the limitations of claims 5, 12, and 



11 



PACE 13/17 ■ RCVD AT 2/18/2004 1 :08:38 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-1/0 * DNIS:8729306 * CSID:440 729 7465 * DURATION (mm-ss):08-16 



Feb 18 2004 2:15PM DHURELIO & MRTHEUS, LLC 



(440) 



729-7465 



p. 14 



Serial Number:09/735.025 Dpcket Number: 1Q002627-1 

19. Accordingly, Applicant requests the rejection of claims 5, 12, and 19 be 
withdrawn in addition to the reasons described above. 

In Item 2 of the Office Action, claims 22, 24-27, 29-32, and 34-36 have been 
rejected 35 U.S.C. §1 02(e) as anticipated by or, in the alternative, under 35 U.S.C. 
§1 03(a) as obvious over Parekh. The standard for anticipation under §102 is stated 
above. With respect to the rejection under §103, a prima fascia case of obviousness 
is established only when the prior art teaches or suggests all of the elements of the 
claims. MPEP §2143.03, in re Riickaert 9f 3d 1531, 28 U.S.P.Q. 2d 1955, 1956 
(Fed. Cir. 1993). For the reasons that follow, Applicant asserts that the rejection of 
claims 22, 24-27, 29-32, and 34-36 is improper. 

Specifically, claim 22 as amended provides the following: 

22. A system for generating a graphical user interface 
(GUI), comprising: 

a processor circuit having a processor and a memory; 
GUI generation logic stored in the memory and 
executable by the processor, the GUI generation logic comprising: 
logic to identify an input item with a default 
value in a template, the template representing a document in 
a markup language file; and 

logic to generate the graphical user interface 
from the template that displays the document as the 
document appears when printed with an input field included 
within the document, the input field being associated with the 
input item, and the default value being initially displayed in 
the input field. 

In this respect, the Office Action states: 

"Parekh discloses logic to generate an input field in the graphical user 
interface, as the document would appear when printed, or in the printed 
information as displayed on the screen represented as the document; 
the input field being associated with an input item is a template, 
wherein the screen elements represented the appearance of the 
documents which are printed and displayed on the screen (page 2, 
paragraph 19, lines 1-10). (Office Action, page 6). 

Applicants respectfully disagree. Specifically, at paragraph 19, lines 1-10, 
Parekh states: 

"With regard to designing customer screens, the screen object 
(created by either the navigation shell or the mini-application) 
defines the customer screen. The screen object initializes screen 
elements from the screen definition file and the canonical template 
file, using canonical template files to create its dependent objects. 
The screen object displays three of its properties: language object, 
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screen ID, and template ID. The language object property identifies 
the language to be used, the country the application will run in, any 
regional properties, among others." 

Applicants assert that nowhere in paragraph 19 cited above does Parekh 
disclose identifying an input item with a default value in a template and where the 
template represents a document in the markup language file and generating a 
graphical user interface from the template that displays the document as the 
document appears when printed with an input field included within the document, the 
input field being associated with an input item and a default value being displayed in 
the input field. For example, where is it that the document is displayed in the 
graphical user interface as it appears as printed? 

Rather, paragraph 19 merely discusses designing customer screen with 
screen objects defining customer screens. In particular, screen objects display three 
properties, language object, screen ID, and template ID. Nowhere does Parekh 
discuss displaying a document as part of a graphical user interface as the document 
appears when printed and including an input field associated with an input item in 
the template with a default value displayed in the input item. 

Accordingly, Applicants assert that the rejection of claim 22 is improper. 
Correspondingly, Applicants assert the rejection of claims 27 and 32 as improper as 
including subject matter similar to claim 27 as amended. Applicants respectfully 
requests that the rejection of claims 22, 27 and 32 as amended be withdrawn. In 
addition, Applicants request that the rejection of claims 24-26, 29-31 , and 34-36 be 
withdrawn as depending from claims 22, 27, and 32, respectively. 

In addition, claim 24 provides for "logic to position the input field within the 

document based upon a set of location coordinates associated with the input item in 

the template." Claims 29 and 34 cite subject matter similar in scope with that of 

claim 24. With reference to claims 24, 29, and 34, the Office Action states: 

"Parekh discloses information for the position of the logic input field 
within the document (page 3, paragraph 44, lines 6-8)." Parekh does 
not disclose the location coordinates. Parekh may not explicitly state 
that location coordinates are used to set the location of the elements of 
a graphical user interface. But Parekh does implicitly state that 
location information within a display is used, wherein concerning 
graphical user interface and windows of a computer display screen, it is 
obvious that these areas are described in terms of location 
coordinates. Hence it is obvious that pixel locations of a graphical user 
interface are described using location coordinates and hence, Parekh's 
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place holders for the screen elements will be based on location 
coordinates." (Office Action page, page 7) 

Applicant respectfully disagrees, at page 3, paragraph 44, lines 6-8, Parekh 
states: "the file has placeholders for each of the screen elements identified in the 
CTF. The device template and the screen content are merged before the resulting 
data (usually HTML) is displayed." 

Applicant asserts that the above excerpt from Parekh nor anywhere else in 
Parekh is there a discussion of positioning an input field within the document that is 
displayed as the document appeared when printed based upon a set of location 
coordinates associated with the input item in the template. Rather, the Parekh 
discusses merging a device template and screen content for display. Accordingly, 
Applicant asserts that the rejection of claims 24, 29, and 34 is improper. 
Accordingly, Applicant requests that the rejection of claims 24, 29, and 34 be 
withdrawn in addition to the reasons described above. 

In addition, claim 25 includes "logic to write a received input value over the 
default value of the input item." In this respect, an input value typed in using the 
graphical user interface is inserted over the default value originally displayed in the 
document that is displayed as printed. It is noted that claims 30 and 35 also include 
subject matter similar in scope with claim 25. 

In this respect, the Office Action states "referring to claims 25, 30 and 35, 
Parekh discloses a means for receiving an input item value and replacing the default 
value of the input item with it (page 6, paragraph 100)." (Office Action, page 7). 

Applicants respectfully disagree. At paragraph 100, Parekh states: 

"basic TextRULE — a rule predefined to handle substitution for text. 
This rule tells the screen template generator to insert a separate 
<TXT ID=xxx> token for the text. The text will also be removed 
before a token is written to the DTF file." 

Applicant asserts that the rule described in paragraph 100 of Parekh 
describes the replacing text with a token. In this respect, the text is stored 
separately and the token incorporates a reference ID that associates the text with 
the position in the template. 

Contrastingly, an input value that is entered by a user into the graphical user 
interface as described with reference to claim 22 is written over the default value that 
is originally displayed. The default value is not retained, and no token that refers to 
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it is incorporated. Accordingly , Parekh fails to show or suggest logic that writes a 
received input value over the default value of an input item. Accordingly, Applicant 
asserts that the rejection of claims 25, 30, and 35 is improper. Accordingly, 
Applicant requests that the rejection of claims 25, 30, and 35 be withdrawn for this 
reason in addition to the reasons discussed above. 

In addition, claims 22, 27, and 32 have been amended herein to correct an 
inadvertent error. Specifically, these claims have been amended to reflect the fact 
that a default value is initially displayed in an input field and not an input item. 



CONCLUSION 

Applicants respectfully request that all outstanding objections and rejections 
be withdrawn and that this application and all presently pending claims be allowed to 
issue. If the Examiner has any questions or comments regarding Applicants 1 
response, the Examiner is encouraged to telephone Applicants' undersigned 
counsel. 



Respectfully submitted, 

Michael J. D'Aurelio 
Reg. No. 40,977 

D'Aurelio & Mathews, LLC 
96 Church Street 
Chagrin Falls, Ohio 44022 
Phone: (440) 729-7450 
Fax: (440) 729-7465 
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